Hmm... Azure DevOps shouldn't be messing with inter-process communication like this; it will replace API keys and similar but only does so in console output that gets posted back, not in between processes.

How did you test that this actually fixes the problem?

Hi, we replaced the vcpgk.exe, with the patched one, and the build went back to normal. As I mentioned, I am no expert when it comes to Azure Devops and vcpkg. Not sure if the content of the response is configurable. We just observed that the content in the response had changed - why - dont know. but the patch solved our situation, and the binaries are cached again.

This works for local builds (developer-machines) as well as for azure devops pipeline builds. (We ensured that the pipeline use the patched vcpkg.exe)

The problem with 'well I think this fixes the problem sometimes' without a concrete understanding of what's going on is that:

1. We might be making changes for no actual reason and what really happened is that something else changed. A common example might be accidentally getting an ancient or otherwise different copy of vcpkg containing bugs that we already fixed, and when steps are taken to try to insert a test copy, that forces everything to be current.
2. Without an understanding of what happened, we are extremely likely to break it again.

After some deep dive it turned out that the azure devops returns a different string in bad request response.

I guess I'm looking for an explanation of how we got here.

Closing due to no response in 6 months. We need a demonstration that this actually fixes anything before we can proceed.